Fix cross-Node service access when AntreaProxy is disabled #2318
Conversation
|
/test-all |
Codecov Report
@@ Coverage Diff @@
## main #2318 +/- ##
==========================================
+ Coverage 62.04% 65.47% +3.42%
==========================================
Files 281 281
Lines 21746 21735 -11
==========================================
+ Hits 13493 14231 +738
+ Misses 6849 6057 -792
- Partials 1404 1447 +43
Flags with carried forward coverage won't be shown. Click here to find out more.
|
tnqn
force-pushed
the
fix-no-antrea-proxy
branch
from
f61b5a6
to
08732ce
Compare
|
/test-all |
|
/test-whole-conformance |
tnqn
force-pushed
the
fix-no-antrea-proxy
branch
from
08732ce
to
38addb5
Compare
pkg/agent/openflow/pipeline.go
Outdated
| // kube-proxy is used). In this case the destination IP address of the reply traffic is the Pod which initiated the | ||
| // connection to the Service (no SNAT). We need to make sure that these packets are sent back through the gateway | ||
| // so that the source IP can be rewritten (Service backend IP -> Service ClusterIP). | ||
| // 2) when hair-pinning is involved, i.e. for connections between 2 local Pods belonging to this Node and for which |
There was a problem hiding this comment.
"for connections between 2 local Pods belonging to this Node and for which NAT Bis performed"
How about: "connections between 2 local Pods on the Node, for which NAT is performed"?
There was a problem hiding this comment.
Thanks, will update after running all CI tests
There was a problem hiding this comment.
I found the first sentence is almost same as the one in ovs-pipeline, unified them. Not sure if you mean removing the leading "for" or not. The latest version is "when hair-pinning is involved, i.e. for connections between 2 local Pods, for which NAT is performed." Let me know if it works for you.
There was a problem hiding this comment.
I think we can remove the leading "for", but we could keep it too.
|
@tnqn : question - is it a regression (hope it was not introduced by my SNAT changes..)? Otherwise, we did not find it earlier. |
|
/test-all |
|
/test-ipv6-all |
|
/test-all-ipv6 |
tnqn
force-pushed
the
fix-no-antrea-proxy
branch
from
38addb5
to
062d2c4
Compare
When AntreaProxy is disabled, if the reply traffic of a connection that has been processed by iptables/ipvs rules (of kube-proxy) is received from the tunnel interface, its destination MAC would be rewritten twice because it would have both gatewayCTMark and macRewriteMark set. The latter rewriting would overwrite the former one and would cause the packets to be delivered to the destination Pod directly without doing reversed NAT in the host netns. This patch fixes it by making the pipeline rewrite the destination MAC as most once. It moves the gatewayCTMark related MAC rewriting flow to l3ForwardingTable, to make L3 forwarding decision in same table uniformly. It also simplifies the two gatewayCTMark related flows by matching the direction of traffic which ensures the flow doesn't apply to traffic from the gateway interface. Signed-off-by: Quan Tian <[email protected]>
tnqn
force-pushed
the
fix-no-antrea-proxy
branch
from
062d2c4
to
c637f57
Compare
Removed leading "for" and corrected the commit message, thanks for reminding. |
|
/test-all |
|
/test-e2e |
|
/skip-e2e e2e once succeeded and the latest failure was for "TestFlowAggregator" which has been tracked in #2283 |
When AntreaProxy is disabled, if the reply traffic of a connection that
has been processed by iptables/ipvs rules (of kube-proxy) is received
from the tunnel interface, its destination MAC would be rewritten twice
because it would have both gatewayCTMark and macRewriteMark set. The
latter rewriting would overwrite the former one and would cause the
packets to be delivered to the destination Pod directly without doing
reversed NAT in the host netns.
This patch fixes it by making the pipeline rewrite the destination MAC
as most once. It moves the gatewayCTMark related MAC rewriting flow to
l3ForwardingTable, to make L3 forwarding decision in same table
uniformly. It also simplifies the two gatewayCTMark related flows by
matching the direction of traffic which ensures the flow doesn't apply
to traffic from the gateway interface.
e2e tests for cross-Node service access are added to cover this scenario
with AntreaProxy disabled.
Fixes #2319
Need to backport to 0.13, 1.0, and 1.1.